All clients must connect to a central JAM server in order to communicate to each other. The server must be prepared to accept connections from any client that implements the JAM protocol, however these clients may potentially send malformed data. Knowing this, it is important the server be designed with robustness and stability in mind -- a single client failing must not bring down the entire server. It must also attempt to be scalable, potentially needing to support multiple hundreds of users at a time while still maintaining high performance.

\begin{figure}[ht!]
	\centering
	\includegraphics[scale=0.5]{images/server_arch.png}
    \caption{Server architecture diagram}
    \end{figure}

Our server architecture takes inspiration from the model-view-controller architecture, aiming to separate the different concerns of the server as much as possible. There are three controllers: the \textbf{network} controller which accepts and handles connections on a global scale; the \textbf{client} controller which handles communication between server and one specific client - the intention being that there is a client controller instance for each connected client; and the \textbf{database} controller which handles and abstracts operations on the database. We then have models to represent users and channels as well as models to represent the current state of specific clients and the server. Finally, the communication between client and server represents the ``view'' component of the model-view-controller architecture. 

The server does not fit into the model-view-controller architecture exactly, as it tends to be used for GUI applications. However, it was still useful in order to create a basic structure to expand upon. There are, additionally, a number of utility components that help implement the protocol in a way that makes it easily extendable, and allows messages to be created and sent without underlying knowledge of the specific protocol syntax itself. These components provide what is essentially the main logic for the JAM server by implementing the actions required once a particular message is received.

\subsection{Network Controller}

The network controller is intended to simply take in connections from the listening socket. Once a connection attempt has been made, the network controller should accept that connection and create a client controller to manage that connection. A new thread should then be spawned in which the client controller will run, allowing all connections to be handled simultaneously in their own separate unit. Once the connection has been accepted and passed off to the client controller, the network controller should resume waiting for new connections until the server is shut down. The network controller should keep track of system state by utilising the server model.

\subsection{Client Controller}

The client controller handles a connection between the server and an individual client. Launched in it’s own thread by the network controller, the client controller should read in messages from the client socket, utilising the protocol framework to parse and process those message. In addition to this, there should be functionality for tracking messages sent to the client that are awaiting a response, allowing responses to be easily matched up to their original message via their transaction ID. It should also provide functionality for providing regular heartbeat checks on the client, as well as tracking the state since the last heartbeat, disconnecting the client if they fail the heartbeat check. Additional state tracking and information storage, such as the channels the user is currently in, should be made using the client model as defined later on in this section.

\subsection{Storage}
As part of designing the overall architecture of the system, we identified data which we should, potentially, be persistent across client and server sessions. We discussed various methods of storing such data. This included storing them in a file, using object serialisation within Java. While this method would have been adequate for the current scale of the system, we decided that using an SQL database would allow for greater flexibility in the longer term.

The class diagram of the SQL component which we developed is given in figure 6.2.

\begin{figure}[ht!]
	\centering
	\includegraphics[scale=0.65]{images/sqlcontroller.1}
    \caption{SQLController class}
    \end{figure}

Our design is sufficiently abstract to allow any database server, which implements the SQL standard and has a JDBC driver, to be connected to the system. In our particular, we used SQLite. We felt that SQLite was appropriate for the current scale of the system, and it allowed us to run the server code on various machines without setting up external database connections. However, as discussed above, it has been designed to allow the system to scale.

As the diagram shows, the SQLController class uses the singleton design pattern, and it’s singleton instance is the only object which opens and maintains a connection to the database. This class allows has methods which take an object-relational mapping; that is, a mapping between that object's attributes, and attributes within a relational database. This entirely abstracted, in the sense that the methods takes a \texttt{HashMap} of attribute values, and an \texttt{ArrayList<String>} of corresponding column names. This approach allows for complete extendability.

\subsection{Models}

The server design includes models for different entities within the system. These models contain the state information held about a particular entity, and the actions which can be performed which change the entity's state. The four models in the system are described below.

\begin{itemize}
\item \textbf{User}
We decided to store the following details about a user: First name, last name, e-mail, password, avatar, display name, contacts and favourite channels. 

There are getters and setters for each of these fields, with the exception of e-mail. The user’s e-mail address will be used as their unique identifier, and as a result cannot be changed. We decided that these details would be held in persistent storage, and as a result the User model contains methods which call the \texttt{SQLController} to populate the User’s attributes, given a user’s e-mail address.

\item \textbf{ClientModel}
The state which is held about a particular client is the User that is associated with the client connection, and a mapping of the channels that the client is active in. In the event that the client is not logged in, the user attribute will be set to \texttt{null}.

The methods of the ClientModel include getters and setters for the channel mapping and user attributes. In addition, there are methods which check if the client is logged in, and to check if a client is participating in a particular channel.

\item \textbf{ServerModel}
We include a ServerModel which contains maps of active channels, and currently logged in users. 

There are methods which allow channels to be added and removed, and for their existence to be checked. In addition, there are methods which add and remove users from the currently logged in map, and check if a user is logged in.

\item \textbf{Channel}
The Channel model has attributes for the name of the channel, a set of users participating in that channel, and a list of user which have been invited, but have not yet accepted/declined the invitation, to the channel. In addition, there is a boolean variable to show whether or not the channel is locked.

The methods provided allow for adding and removing users from the invited and active lists, getting the name of the channel, and setting and checking the lock variable.
\end{itemize}

\subsection{Protocol Framework}

The protocol framework helps with parsing and processing the incoming messages from the client socket. These components provide abstractions of the underlying JAM protocol allowing messages to be formed and sent in an easy and consistent way, as well as implementing what happens when a particular message is received.

\begin{figure}[ht!]
	\centering
	\includegraphics[scale=0.65]{images/server_arch.1}
    \caption{Server class diagram}
    \end{figure}

It should be noted that figure 6.3 gives a non-exhaustive representation of the class structure. \texttt{ClientActionJoin} and \texttt{ClientRequestUserInfo} are examples of client action and client request classes, and all other actions and requests, as defined in appendix A, are implemented in the same manner. To provide a full class diagram would create a diagram which is both unwieldy, and less useful than the one given.

The \texttt{MessageParser} is the key component of the protocol framework. Upon receiving data from the socket, the client controller should pass the data straight to the message parser to process the message. The message parser creates the appropriate concrete message instance for that particular received message if it was valid, throwing it away and responding with a failure response otherwise. Once the concrete message instance has been created, the appropriate logic can then be called to perform whatever process is required for that particular message as defined by that message's concrete instance, such as relaying a message to other clients or noting that the client has responded to a particular server message.

There are a number of abstract classes used in defining messages. All of these classes are based off of the \texttt{Message} class which forces any inheriting class to define a getter for its unique keyword. This is essential in order to identify a particular type of message, being utilised by the message parser to create the correct concrete instance. Following this, the messages classes are split up into two groups -- client messages and server messages -- in order to provide further abstraction. The client message group represents messages sent from the client and received by the server, whereas the server message group represents messages sent out by the server.

For client messages, the abstract class \texttt{ClientCommand} defines an abstract function process which any inheriting class must implement. This function is called by the message parser after instancing the concrete type and should contain the logic in order to actually process that message by utilising the \texttt{ClientController} (which is the client that sent the message) passed to it. The constructor for this abstract class is passed a \texttt{Scanner} which can then be used to get the message arguments. All concrete client messages inherit from this class. There is also a generic class \texttt{ClientResponse} which is used to parse responses to server messages from the client, instantiated by the message parser if the sent keyword matches any server messages.

For server messages, there is the abstract class \texttt{ServerMessage} which defines that any inheriting class must implement the function \texttt{getArgumentList}. This is used when translating the message into the protocol format for sending by the \texttt{toString} function. The abstract class \texttt{ServerCommand} provides a \texttt{process} function that is called upon receiving a response to a server message, which can be overridden by the inheriting class to perform any necessary actions. All concrete server messages, such the message used to relay channel messages to users, inherit from this class. The generic class \texttt{ServerResponse} is used when sending messages to the client, simply building up a list of arguments as provided. The intention is that, when a message must be sent to the client for whatever reason, the application simply needs to instance that particular server message type (or the generic \texttt{ServerResponse}) which can then be passed directly to the client controller in order to send that message.

Once defined, this framework makes it extremely simple to expand the protocol -- the main reason for its design. To add support for a new client message, for example, one only needs to create a new concrete class which inherits from the \texttt{ClientCommand} class and then a single line of code to the \texttt{MessageParser} class to recognize that particular message. All logic that deals with that particular message is then kept inside that class, providing encapsulation from the processing logic for other messages. Support for additional server messages can be expanded in a similar manner by inheriting from the \texttt{ServerCommand} class.
